When parties wish to communicate securely over a network, these parties must authenticate each other to ensure that they are, in fact, participating in the communications. One type of authentication protocol involves the use of a third party trusted by both the parties involved in the secure communications. The trusted third party is responsible for authenticating the parties and generating a key which is used for encrypting data sent between these parties.
Another type of authentication protocol involves network access. As an example, a client device wishes to access a network through/behind a network gateway. Since the client device is not, strictly speaking, on the network yet, it is incapable of communicating with a trusted third party residing on the network. But the client device can send data to the trusted third party through the network gateway, and the network gateway cannot modify or unwrap them. After the authentication protocol has completed, the client device and the network gateway are able to share a key that may be used to protect data communicated by users associated with their network devices.
One approach to such mutual authentication using a trusted third party may be found in “Efficient and Timely Mutual Authentication,” Operating Systems Review, v.21 n.1, 1987, pp. 8-10 by D. Otway and O. Rees, discussed in Applied Cryptography, Second Edition by Bruce Schneier, pp 59-60.
Otway-Rees makes use of a trusted third party to distribute keys to two parties. While this protocol provides resistance to replay and cut-and-paste attacks, the trusted third party provides the key used by the two parties, which is considered by many to be a weakness in the networked system. Another weakness with the Otway-Rees scheme is that it does not provide Perfect Forward Secrecy (PFS), namely if the secret either party shares with the trusted third party is compromised then all past traffic can be revealed.
For instance, an example of standard Otway-Rees authentication and key generation for a client device and a gateway server through use of an intermediary device is described below.
The client device generates a nonce (Na) and chooses a session identifier (sess). Thereafter, as represented immediately below, the client device sends its identifier (A), an identifier (B) for the server, session identifier (sess) and this data {Na, A, B, sess} encrypted with a shared key (Kat) previously established between the client device A and the intermediary device T.                A→B: A, B, sess, {Na, A, B, sess}Kat, where “{ }x” denotes data protected by x        
Similarly, the server B generates a nonce (Nb). Thereafter, server B sends its identifier (B) along with the identifier for the client device (A), sess, the encrypted data {Na, A, B, sess}Kat and additional data {Nb, A, B, sess} encrypted with a shared key (Kbt) previously established between the server B and the intermediary device T as represented immediately below:                B→T: B, A, sess, {Na, A, B, sess}Kat, {Nb, A, B, sess}Kbt         
Based on this information, the intermediary device T generates a shared key (Kab) for use by both client device A and server B. The shared key (Kab) is returned to the server B, which subsequently provides Kab back to the client device A. More specifically, with the session identifier (sess), the shared key (Kab) is returned to the server B as part of (i) data {Na, Kab} encrypted with Kat, the shared key between Alice and Trent; and (ii) data {Nb, Kab} encrypted with Kbt, the shared key between the server B and the intermediary device T. This communication is represented immediately below:                B←T: sess, {Na, Kab}Kat, {Nb, Kab}Kbt         
Since the client device A and the intermediary device T are unable to communicate directly to each other, for the client device A to receive Kab, a portion of a message containing Kab needs to pass through the server B. Thereafter, the server B sends the session identifier (sess) along with the encrypted data {Na, Kab}Kat to client device A as represented immediately below:                A←B: sess, {Na, Kab} Kat         
Since the server B has access to key Kbt, it can decrypt {Nb, Kab}Kbt, verify nonce Nb, and retrieve shared key Kab. Similarly, having access to key Kat, the client device A can decrypt {Na, Kab}Kat, verify nonce Na, and retrieve shared key Kab. Now, both client device A and the server B share Kab and can use Kab to communicate securely.
A perceived weakness in this exchange is that the shared key, Kab, is generated and now also known by a third party (Trent). Another weakness, mentioned above, is the lack of Perfect Forward Secrecy that would reveal all past conversation between A and B if either Kat or Kbt is compromised.
What is needed is a way to use the trusted intermediary to authenticate the two parties to each other, and not operate as a key generator.